Feature/INT-1702 - Airline and accommodation sub-tree model alignment - #676
david-ruiz-cko wants to merge 4 commits into
Conversation
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 27 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
🟠 Advisory review: Concerns worth a lookThis PR needs a human approval. Before you give it, these are the things I'd want resolved. This PR realigns airline/accommodation data models with the API spec, fixing cardinality bugs (airline serialized as object instead of array), field type mismatches (CountryCode→String, Long→String for flightNumber), and adds a custom Gson adapter to handle passenger as either object or array. The logic is largely sound but there are several concrete issues worth resolving before approval. Concerns
This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02 |
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 27 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| * global {@code LOWER_CASE_WITH_UNDERSCORES} naming policy and the {@code LocalDate} adapter | ||
| * still apply; this deserializer never maps property names itself. | ||
| * | ||
| * @param elementType the list element type |
| * still apply; this deserializer never maps property names itself. | ||
| * | ||
| * @param elementType the list element type | ||
| * @param <T> the list element type |
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 27 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
|
This branch has not been deployed
2 participants
This pull request introduces several important improvements and corrections to the payment industry data models, focusing on better alignment with the API specification, increased robustness in JSON (de)serialization, and enhanced documentation. The most significant changes include improved handling of polymorphic array/object fields, migration of several properties to more flexible types, and extensive JavaDoc updates for clarity and maintainability.
Improvements to JSON (de)serialization and data model flexibility:
GsonSerializerto handle fields that may be either a single object or an array (notably for airline passenger data), ensuring consistent internal representation as a list and always serializing as an array. This prevents data loss and aligns with the API's flexible input. [1] [2]Industryand related classes to map airline and accommodation properties as lists (List<AirlineData>,List<AccommodationData>) instead of single objects, matching the API specification and fixing previous serialization issues.Data type corrections and deprecations:
CountryCode) to plainStringto accommodate the API's use of both two- and three-letter country codes, increasing compatibility. [1] [2]PaymentContextsAccommodationData,serviceClassinFlightLegDetails,hubModelOriginationCountryinProcessingSettings) to guide developers toward the preferred usage and maintain backward compatibility. [1] [2] [3]Documentation and JavaDoc enhancements:
New features and classes:
PartnerCustomerRiskDatato represent merchant-specific key-value pairs for transaction risk data, supporting new API features and aligning with the latest specification. [1] [2]Property and field corrections:
classOfTravelling,departureDateasLocalDate,numberOfNightsAtRoomRateasString), and clarified optionality and expected formats. [1] [2] [3]These changes collectively improve the SDK's correctness, flexibility, and developer usability when handling payment industry-specific data.